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REMARKS/ARGUMENTS 

I. STATUS OF CLAIMS 

Claims 1-15 remain in this application. Claims 1 and 1 1 have been amended. It 
should be noted that Applicant has elected to amend said Claims solely for the purpose of 
expediting the patent application process in a manner consistent with the PTO's Patent 
Business Goals, 65 Fed. Reg. 54603 (9/8/00). In making this amendment, Applicant has 
not and does not in any way narrow the scope of protection to which Applicant considers 
the invention herein to be entitled and does not concede, in any way, that the subject 
matter of such Claims was in fact taught or disclosed by the cited prior art. Rather, 
Applicant reserves Applicant's right to pursue such protection at a later point in time and 
merely seeks to pursue protection for the subject matter presented in this submission. 

II. CLAIM REJECTIONS - 35 U.S.C. § 103 

The Office Action rejected Claims 1, 2, 4, 6, 7, 9, 11, 12,and 14 under 35 U.S.C. § 
103(a) as being unpatentable over Shah (6,292,832) in view of Rabinovich (6,256,675). 
AppUcant respectfully disagrees. 
Claims 1, 6, and 11 appear as follows: 

1 . A process for determining latency between multiple servers and a 
client across a network in a computer environment, comprising the steps of: 

receiving a request for latency metrics on a server; 

wherein said latency metric request specifies a particular client; 
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wherein a latency management table comprises a list of IP addresses along 
with corresponding Border Gateway Protocol (BGP) hop counts, dynamic hop 
counts, and Round Trip Times (RTT); 

looking up the latency metric for said client in said latency management 

table; 

sending said latency metric to the requesting server; 

wherein only the BGP hop count for said client in said latency 
management table is used for said latency metric upon an initial request for said 
client; and 

wherein the dynamic hop count and RTT data for said client in said 
latency management table are used for said latency metric for subsequent requests 
for said client. 

6. An apparatus for determining latency between multiple servers and 
a client across a network in a computer environment, comprising: 

a module for receiving a request for latency metrics on a server; 
wherein said latency metric request specifies a particular client; 
a latency management table; 

wherein said latency management table comprises a list of IP addresses 
along with corresponding Border Gateway Protocol (BGP) hop counts, dynamic 
hop counts, and Round Trip Times (RTT); 

a module for looking up the latency metric for said client in said latency 
management table; 

a module for sending said latency metric to the requesting server; 
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wherein only the BGP hop count for said client in said latency 
management table is used for said latency metric upon an initial request for said 
client; and 

wherein the dynamic hop count and RTT data for said client in said 
latency management table are used for said latency metric for subsequent requests 
for said client. 

11. A program storage medium readable by a computer, tangibly 
embodying a program of instructions executable by the computer to perform 
method steps for determining latency between multiple servers and a client across 
a network in a computer environment, comprising the steps of: 

receiving a request for latency metrics on a server; 

wherein said latency metric request specifies a particular client; 

wherein a latency management table comprises a list of IP addresses along 
with corresponding Border Gateway Protocol (BGP) hop counts, dynamic hop 
counts, and Round Trip Times (RTT); 

looking up the latency metric for said client in said latency management 

table; 

sending said latency metric to the requesting server; 

wherein only the BGP hop count for said client in said latency 
management table is used for said latency metric upon an initial request for said 
client; and 
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wherein the dynamic hop count and RTT data for said cUent in said 
latency management table are used for said latency metric for subsequent requests 
for said client. 

In particular, The Office Action states: 

"Rabinovich teaches only the BGP hop count for said client in said latency 
management table is used for said latency metric upon an initial request for said 
client (e.g., col. 20, lines 10-20)." 

However, this is an incorrect interpretation of Rabinovich. Rabinovich teaches 
away from what the Office Action states by teaching that BGP hop count is used for 
distance calculations for all requests. Rabinovich teaches that a mapping function is used 
that calculates a distance using the number of BGP hops from a host's AS to another AS, 
A, in combination with the OSPF cost of delivering a message from the host to the 
nearest border router that advertises the extemal route to A within the host's AS. 
Col 19, lines 6-11 state: 

"The answer to these questions would differ slightly depending on the 
protocols considered. To be specific, assume that BGP is used to route EP 
messages between autonomous systems (AS) of the Intemet, and OSPF is used to 
route IP messages within an autonomous system, the most common (and 
recommended) open routing protocols." 

In col. 19, line 58-col. 20, line 9, Rabinovich states that the BGP hops are used in 
conjunction with the OSPF cost to calculate distance (emphasis added): 

"The request distribution service extracts the following information from 
the routing databases of intemal autonomous systems, using, for example, the 
fimctionality provided by Distributed Director from CISCO. 
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The BOP routing da^ase in every internal autonomous system IAS is 
queried toobtain flections Border R„„ters(A.IAS,andBGP ,„ps(A.IAS) TTe 

amotion OSPF.metric (b, s,, for every border router br and evetyKoses. 
Using this info^ation, the request indirection set^ice computes the 

-pping (A.times.hostHdis,ance for e.h autonomous system A and intenta, 

host host, Where distance is t^tesented as a pair in which H„. c.™p..e.. is 

tte number orBGP .ops h.s,, ,„ ^ 

-o.d component is the OSPF cos, of deliveH., , 

-..rest border router tba. adver«sed .he externa, rouu to A „«.o b^fs 

autonomous system." 

R^b^ovich fertherdescribes the two component fonnuia in co,. 20, lines 9-20 

a^dspeci^esd^ttheBOPhopsandOSPPcostvaiuesareintesraipartsofthedistance 

formula: 

"Formally: 

, distanceKBOP.hops (A, IAS (host),, min [OSPF.metric (r, host). 

eBorder Routers (A, US (host)))), 

whereMS(host)denotesthe(intemal)AStowhichhostbe,„ngs 

».reeme..„i.h,n.en.e.ro..i.„ Which „«.sesBGP.,r.„.ean.ess„e to 
«.e destination, autonomous syste™ and then OSPF .„ deliver it withi, 

autonomous system, assume that distance rrf 

distance (d,, d2) is greater than distance (d', 

^ « service uses this mapping 

.0 find the closest host to a given Cien, request, theteby h„p,emen,i„g a tUnction 
l«<Node (X, c) in dte request distribution method." 
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It is clear from Rabinovich that his invention's request indirection service uses 
both the BGP hops and the OSPF cost functions to calculate the distance mapping for 
hosts. 

Rabinovich makes no mention of wherein only the BGP hop count for said cUent 
in said latency management table is used for said latency metric upon an initial request 
for said chent as claimed in Claims 1, 6, and 11. 

To combine Shah and Rabinovich as the Office Action suggests would result in a 
distance calculation used for every host distance calculation. The calculation would use 
the BGP hops and the OSPF cost factors for every host calculation. This is not what is 
claimed in Claims 1, 6, and 11. 

Further, the Office Action states that: 

"It would have been obvious to one of ordinary skill in the art at the time 

the invention was made to combine Rabinovich with Shah because if the system 

is initiating a request with only the BGP hop count stored in a table then it would 

have been obvious to only use the BGP hop count to determine latency because 

there is no other parameters to utilize in the initial request." 

However, the Office Action's rationale for what would have been obvious to one 
of ordinary skill in the art at the time the invention was made is unfounded because, as 
discussed above, Rabinovich teaches that BGP hops are used in conjunction with OSPF 
costs in all host mapping distance calculations. Rabinovich relies on the BGP hops for 
all host mapping distance calculations and therefore would not have suggested that the 
BGP hop count would be useful only for the system initiating a request, as the Office 
Action suggests. There is no teaching or suggestion in Shah or Rabinovich to combine 
the references as suggested by the Office Action. 
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Therefore, Shah in view of Rabinovich does not teach or disclose the invention as 
claimed. 

Claims 1, 6, and 1 1 are in allowable condition. Claims 2, 4, and 7, 9, and 12, 14 
are dependent upon independent Claims 1, 6, and 11, respectively. Therefore, Applicant 
respectfully requests that the Examiner withdraw the rejection imder 35 U.S.C. § 103(a). 

' III. CLAIM REJECTIONS - 35 U.S.C. § 103 

The Office Action rejected Claims 3, 8, and 13 under 35 U.S.C. § 103(a) as being 
unpatentable over Shah (6,292,832) and Rabinovich (6,256,675) and in view of what is 
well known in the art. . 

The rejection under 35 USC § 103(a) is deemed moot in view of AppHcant's 
comments regarding Claims 1, 6, and 11, above. Claims 3 and 8 and 13 are dependent 
upon independent Claims 1, 6, and 11, respectively. Therefore, Applicant respectfully 
requests that the Examiner withdraw the rejection under 35 USC § 103(a). 

IV. CLAIM REJECTIONS - 35 U.S.C. § 103 

The Office Action rejected Claims 5, 10, and 15 under 35 U.S.C. § 103(a) as 
being unpatentable over Shah (6,292,832) and Rabinovich (6,256,675) and in view of 
McCanne (6,415,323). 

The rejection under 35 USC §103(a) is deemed moot in view of Applicant's 
comments regarding Claims 1, 6, and 11, above. Claims 5 and 10 and 15 are dependent 
upon independent Claims 1 , 6, and 1 1 , respectively. Therefore, Applicant respectfully 
requests that the Examiner withdraw the rejection under 35 USC §103(a). 
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V. MISCELLANEOUS 

Applicant respectfully requests that a timely Notice of Allowance be issued in this 

case. 

The Applicants believe that all issues raised in the Office Action have been 
addressed and that allowance of the pending claims is appropriate. Entry of the 
amendments herein and further examination on the merits are respectfully requested. 

The Examiner is invited to telephone the undersigned at (408) 414-1214 to 
discuss any issue that may advance prosecution. 

No fee is believed to be due specifically in connection with this Reply. To the 
extent necessary, Applicants petition for an extension of time under 37 C.F.R. § 1.136. 
The Commissioner is authorized to charge any fee that may be due in connection with 
this Reply to our Deposit Account No. 50-1302. 

Respectfully submitted, 

HICKMAN PALERMO TRUONG & BECKER LLP 



Dated: August /^ ,2005 




Kirk D. Won^ 
Reg. No. 43,284 



2055 Gateway Place, Suite 550 
San Jose, California 95110-1089 
Telephone No.: (408) 414-1080 ext. 214 
Facsimile No.: (408) 414-1076 
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